The present invention concerns transmitting data over local area networks (LANs) and pertains particularly to low latency bridging between high speed bus networks.
For busses that operate according to the Small Computer Systems Interface (SCSI) protocol, I/O data transactions are initiated and controlled by an initiator (typically a processor or SCSI protocol bridge) which is connected to a SCSI bus. A SCSI protocol bridge is a device which manages SCSI processes between a computer and associated SCSI target devices.
Also connected to a SCSI bus are one or more targets. For example, a target is typically a computer peripheral device such as a hard drive, a CD ROM, a scanner or a printer. When operating in accordance with the SCSI protocol, an initiator is required to manage multiple concurrent input/output (I/O) data transactions in various stages of completion.
When using a SCSI protocol bridge, it is difficult to maintain temporal transparency and to maintain the ability to multiplex many concurrent processes in an application. It is especially difficult for outbound processes, which are characterized by having a data out phase (in response to a SCSI-2 DATA.sub.-- OUT command). An outbound process is a transfer (of a copy) of some buffer of data from a computer (initiator) to a SCSI peripheral device (target). An outbound process is typically a SCSI write operation, for example.
The difficulty arises from two problem areas. The first area is due to the SCSI-2 protocol and SCSI target device implementations. The SCSI peripheral device may demand the data either immediately after receiving the associated command or at some significant delay after receiving the associated command. In the immediate case, it is desirable to have the data available to give upon demand quickly for lowest latency and best SCSI-2 bus utilization.
The second problem area is due to the nature of the bridging and the off the shelf components used to perform direct memory access (DMA) of data from the computer. In order to have efficient delivery of this data, the data must be "asked for" in sufficiently large portions to amortize the overhead of "asking" for each portion of data.
Typical DMA engines which deliver data in large portions are either only efficient with, or may only support, a report upon the complete arrival of the data requested. This leads to a cost tradeoff for implementation of a SCSI protocol bridge between latency and efficient utilization. In order to reduce latency to a minimum for one input output (I/O) data out process, risks under-utilizing the shared SCSI bus due to not having the data in time.
To most efficiently utilize the SCSI bus, the data should be pre-stored in the SCSI protocol bridge just in case the SCSI target devices demands it immediately after receiving and decoding the command. However, to wait for notification of data arrival induces a latency corresponding to the amount of data to be transferred per portion of data requested, which, must be maximized for efficiency.
These problems are exacerbated by particular SCSI protocol bridges. For example, a Fibre Channel SCSI-3 to SCSI-2 bus bridge, when acting as a SCSI-3 target, doesn't receive as quick a response to a DATA.sub.-- OUT command as the response of a SCSI-2 target. This is because SCSI-2 uses a half duplex channel so that the entire SCSI-2 bus bandwidth is utilized when a SCSI target and initiator are transferring data. In this way SCSI-2 is optimized to minimize such latencies.
In contrast, the only penalty for a delay of data delivery with SCSI-3 run across Fibre Channel or other full duplex links, is the effect it has on that particular I/O process. Therefore, there are several SCSI-2 chip interfaces to various processor busses, memory busses and I/O busses which provide for a very low latency initiator response to a target's data transfer demands. However, there's a very loose temporal relationship inherent between the request for data and its subsequent arrival with Fibre Channel and similar full duplex links.
One solution is for the SCSI protocol bridge to launch a SCSI write process on the SCSI-2 bus at the earliest opportunity (e.g., as soon as the SCSI protocol bridge is notified that a SCSI-3 data out (FCP.sub.-- DMND) command has been received and processed). However, launching the SCSI write process immediately can lead to a stall at the SCSI-2 peripheral device which, if a SCSI-2 parallel bus, also prevents other I/O process utilization of the SCSI-2 parallel bus during the stall. In addition, this may cause significant delay for other I/O process utilization if an opportunity to avoid mechanical movement is missed due to the delay in the SCSI Initiator interface providing data (such as addition disk rotations and/or falling out of tape streaming modes).
Another solution is to risk some low bus utilization and forward the SCSI write process at the earliest opportunity after requesting a portion of the data. In other words, smaller portions of data are requested over the SCSI-3 bus allowing for lower latency and quicker notification for an initial portion of data. One problem with this approach is that there are significant overheads associated with each portion of data requested. The addition of a relatively small portion for the purpose of launching I/O process through the SCSI protocol bridge has a significant performance cost. Another problem is that the SCSI-2 bus can be stalled significantly because there is no guarantee that asking for the data to be transferred over a SCSI-3 will result in timely delivery of the data. Further, the delays can pile up since there can be significant latencies for each subsequent portion requested. The more, smaller portions of data delivery, the more chances there are for added latency in the return of the requested data.
Another solution is to buffer a sufficient amount of data in the SCSI protocol bridge before ever launching the SCSI write process on the SCSI-2 side. This approach has the disadvantage of adding a latency that scales with the combination of the amount of data needed and its latency, as discussed above.